Add docs/benchmarks/performance-igx-orin.md, the IGX Orin devkit counterpart
to the DGX Spark performance report, produced by the same sweep scripts with
BENCH_PLATFORM=igx. Single-rep (REPEATS=1) C++-loopback numbers for DPDK raw
(kind: device GPUDirect), RoCE SEND, TCP, and UDP, with an "Single-rep figures"
callout in lieu of error bars.

Headline: the offload-heavy bulk paths (DPDK raw, RoCE >=64 KB) hit the same
~96-98 Gb/s NIC/PCIe ceiling as Spark, while the CPU-bound paths trail Spark in
proportion to the per-core CPU gap -- IGX's 1.97 GHz Cortex-A78AE cores vs the
3.9 GHz Cortex-X925 cluster the Spark bench pins onto. The single-pair 1 MiB TCP
ratio (17.8 vs 31.6 = 1.78x) tracks the clock ratio, confirming the wire is not
the limit.

- scripts/plot_mq_payload_sweep.py: parameterize the chart title (optional 3rd
  arg) so it is not hardcoded "DGX Spark"; render docs/images/igx-mq-payload-sweep.svg.
- Wire the page into mkdocs.yml nav, the README Documentation table, and the
  AGENTS.md docs layout list; add a Spark->IGX cross-link on the Spark page.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Denis Leshchev <dleshchev@nvidia.com>

Re-ran the full IGX Orin suite with REPEATS=3 (BENCH_PLATFORM=igx) and replaced
the single-rep figures with 3-rep means. The numbers confirm the single-rep
draft almost exactly (run-to-run spread <=0.4 Gb/s on DPDK/RoCE, <=0.3 on
sockets), so the narrative is unchanged. Notable corrections from the cleaner
data:

- RoCE server RX core is ~4% busy (idle), not ~76% -- the expected RoCE RC
  signature (HCA writes straight to memory), matching Spark. The single-rep
  draft mis-attributed a busy worker core.
- DPDK CPU-utilization table replaced with an honest note: per-core busy% is
  unreliable on the nohz_full/rcu_nocbs isolated cores (tickless /proc/stat
  accounting under-counts and shifts run-to-run at identical throughput), so we
  don't publish precise per-core figures -- the throughput-vs-Spark gap is the
  real CPU-bound evidence.
- Regenerated docs/images/igx-mq-payload-sweep.svg from rep-averaged data.

Methodology callout updated to REPEATS=3; Reproduce section exports REPEATS=3.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Denis Leshchev <dleshchev@nvidia.com>

…t results

The IGX socket pairs were pinned to the isolated cores (9 10 11 0) that DPDK/RoCE
use for poll-mode busy-spin. That tuning is wrong for kernel sockets: the
nohz_full/rcu_nocbs cores defer timers/RCU and starve the syscall path, and core
0 is the single sink for all NIC RX softirqs. Re-pin SOCKET_PAIR_CORES to the
non-isolated cores (1 2 3 4) in the irqaffinity=0-8 pool and re-run TCP+UDP at
REPEATS=3.

Effect: small-message TCP now scales ~linearly (1000 B: 4.2/8.5/16.7 over 1/2/4
pairs vs 3.6/7.1/12.1 before) and UDP improves across the board (8 KB 4-pair
10.5 vs 9.3 Gb/s). Large-message TCP is essentially unchanged because it is
receive-side bound, not app-core bound.

Report update: refreshed the TCP/UDP tables and added the measured root cause for
the large-message TCP ceiling -- all NIC RX softirq serializes on a single core
(cpu0 runs ~70% in softirq, every other core sees no NET_RX), so the four flows'
copy-heavy receive paths share one softirq core. RSS/RPS is not spreading receive
work; lifting it would need RX-softirq spreading, not more app cores. Documented
the socket-vs-poll-mode core split in the System-under-test table.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Denis Leshchev <dleshchev@nvidia.com>